「為什麼明明只是加個按鈕，卻搞了兩個禮拜？」
如果這句話讓你苦笑，那你來對地方了。今天我們要聊的不是技術，而是那些讓每個工程師都想翻桌的日常——那些我們不願承認，卻每天都在發生的開發困境。
身為一位軟體工程師，不論你是 Web 前端、後端，甚至是全端工程師，或是你是做 App 的工程師，一定都經歷過上線前還在 debug 的緊張時刻、上線後半夜被 On Call 叫醒要上 Hot Fix 的痛苦。那種在凌晨三點，眼睛盯著滿螢幕的 log，腦袋卻一片空白的感覺，我想你一定不陌生。
最崩潰的是什麼？是那種「明明在我的電腦上可以跑」的無力感。
你是否也經歷過每個 Sprint 的容量超出開發能量、或是 Sprint 中間有隕石砸下來，不得不用一些 Work Around 的方式去處理需求。然後下個專案，你發現自己又在寫一模一樣的東西，只是換了個名字、改了點參數。你開始懷疑：我到底是在創造價值，還是在當高級碼農？
這個狀況你或多或少都有遇過——當你以為一個 1 Point 的 User Story 你很快可以做完，而你確實也在一個下午做完了，但在 QA 階段或是 UAT 環節，發現需要調整，而變成無限長大的 User Story，或是一個簡單的 HotFix 最後卻變成一個 21 Point 的大功能。那種「早知道就不要說這很簡單」的懊悔，相信每個工程師都體會過。
這個場景你是否也十分熟悉：
早上 Standup Meeting，PM 說：「這個功能很簡單，就是加個按鈕。」兩週後，你還在處理各種 edge case、調整 responsive design、修復不預期的狀態管理問題。那個「簡單的按鈕」牽動了整個系統架構。
更諷刺的是什麼？你發現自己正在寫三個月前寫過的功能——另一個專案、另一個 client，但本質上是一樣的東西。你熟練地複製貼上，心裡想著：「我是工程師還是打字員？」
如果這些場景讓你心有戚戚焉，恭喜你，你不孤單。這就是我們傳統開發模式下的日常——不斷地重複、不斷地救火、不斷地懷疑人生。
我在職涯中待過不同的團隊，看過不同的開發流程，有使用看板、瀑布、敏捷開發的，有成功、也有失敗的。實話實說，這些開發流程都沒有好壞，但確實與團隊文化有非常大的關聯性。
而透過幾次失敗的經驗，筆者歸納出了一些開發流程中開發團隊容易遇到的核心問題，如下：
「Nico 離職了，現在沒人知道這個部署腳本怎麼運作。」
這句話在每個團隊都上演過。我們花了無數時間累積的 domain knowledge，隨著人員流動不斷流失。新人加入時，你試圖解釋系統架構，但發現連你自己都記不清當初為什麼這樣設計。
需求文件？別鬧了，能有任務的卡片留著就已經很不錯了，有時說不定 PM 都不記得功能的全部樣貌。通常你也不會期望註解就能說明清楚當初的開發背景跟需求脈絡。
真實案例：曾經某位同事非常不喜歡寫文件，在需求文件也沒有的情況下，根本也沒有人看得懂他寫的程式為什麼要這麼做。最後他離職時，我們花了整整一個月才搞懂他負責的支付模組邏輯。
知識管理不是技術問題，是人性問題——我們總是高估自己的記憶力，低估知識傳承的重要性。
需求是怎麼變形的？讓我們追蹤一個功能的誕生：
每一次轉譯都是一次失真。更糟的是，這些溝通佔據了我們大量時間：
算算看，一個兩週的 Sprint，光是會議就佔了 20+ 小時。而真正寫 code 的時間？可能不到一半。
筆者最長的 Sprint Planning 開會時間是可以開到一天的（PO 解釋需求、團隊估點、Task Break Down），而且這還不是最終的需求確認，需求經由討論設計都還可能持續變動。
統計一下你的職業生涯，有多少時間花在：
這些不是創造性工作，是機械性勞動。但因為每個專案「稍微有點不同」，我們無法真正重用。於是陷入了「複製-貼上-修改」的無限循環。
一位資深工程師的自嘲：「我寫了十年程式，其中五年在寫 for 迴圈，三年在處理 null pointer，剩下兩年在 Google 怎麼垂直置中。」
即便是筆者很崇尚 Clean Code 的精神，也不免還是需要很多重複的工作。光是 Terraform 在沒有模組化的時候，你就有可能一直重複再重複地寫相同的 resource 定義。
「這個先 hardcode，之後再改。」——每個工程師都說過的謊言。
技術債是這樣累積的：
真實統計：一個五年的專案，平均有 40% 的程式碼是技術債。維護這些程式碼的成本，是開發新功能的 3-4 倍。
但為什麼我們還是不斷累積技術債？因為 PM 永遠在問「什麼時候可以上線」，而不是「程式碼品質如何」。
理想很豐滿，現實很骨感。我們工程師都很想要自己維護的專案是漂亮的，至少都遵循了 SOLID 或是 Clean Code 的精神，但現實的隕石跟十分著急的 PM 以及憤怒的老闆通常不會在乎我們的程式有多麼漂亮，畢竟漂亮的程式碼的價值可能只有我們知道而已。
早上 9 點，你充滿活力，一小時寫了 200 行高品質程式碼。
下午 3 點，你盯著螢幕發呆，一個簡單的 function 想了半小時。
晚上 7 點，你開始懷疑自己是不是該轉行。
人類的認知能力有限。研究顯示，程式設計師一天真正高效的時間只有 2-4 小時。剩下的時間在：
我們試圖用各種方法提升效率：番茄鐘、GTD、時間管理...但本質問題沒變：我們在用石器時代的大腦，處理太空時代的複雜度。
筆者已經習慣同時寫程式、開會、部署的生活，半夜的時候還可以讓夢中的自己去設計明天預計完成功能的架構。但這樣的「效率」，其實是在透支未來的生產力。
討厭那麼麻煩的團隊流程嗎？我們有時候會想，有時候想單純地寫程式做產品，到最後都在花時間 build team。但是如果你是團隊開發者，至少還有人可以討論、分工。
但個人開發者？你要同時是面對一些挑戰。
即便你擁有所有領域的能力，你也沒有那麼多時間。時間是最公平的資源，每個人一天都只有 24 小時。
每個決定都要自己做，沒有人討論，沒有人 review。做對了沒人誇，做錯了沒人救。
最諷刺的是，市場上充斥著「一個人做出獨角獸」的故事，彷彿你的失敗只是因為不夠努力。但現實是：一個人的力量，在現今的技術複雜度面前，真的太渺小了。
讀到這裡，你可能會問：既然問題這麼明顯，為什麼我們還是無法解決？
答案很殘酷：因為這些不只是技術問題，更是系統性問題。
更深層的原因是，我們一直在用「管理」的思維解決「工具」的問題。敏捷、Scrum、看板...這些都是在優化流程，但寫程式的本質困難並沒有改變。
就像你不能期待跑得更快的馬車能夠競爭過汽車，我們需要的不是更好的流程，而是革命性的工具。
好消息是，這個工具已經出現了——AI 輔助開發。它不是另一個框架，不是另一個方法論，而是真正能夠理解你、協助你、放大你能力的夥伴。從 GitHub Copilot 到 Claude，從 Cursor 到 Kiro，AI 正在改變開發的本質。
下一篇，我們將深入探討為什麼連敏捷開發都無法解決這些根本問題，以及新的曙光在哪裡。
在那之前，我想問問你：上述的問題中，哪一個最讓你痛苦？ 歡迎在留言區分享你的故事。
記住，承認問題是解決問題的第一步。而我們，正站在改變的起點。
iThome鐵人賽
看影片追技術
看更多
